-
Notifications
You must be signed in to change notification settings - Fork 448
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: support loading init img from url #2
Conversation
yeah I need to think about this for a minute. I'm leaning towards supporting an input PIL image. Having a web request be possible inside the library doesn't feel quite right |
on the other hand, just putting in a url would be so convenient... but yeah seems like a not clean api and also less secure. Trying to think how to have it both ways. |
If we want to make it super easy to use then just exposing a raw PIL image interface is not ideal. Here's an idea to get the flexibility I need but still keeping it easy to use. A new class Static Methods (or however you do this in python): Also ideally we can share one Usage:
|
Yes. I was thinking something similar although I think it needs to lazy load the images or otherwise you end up consuming lots of memory when the queue of prompts is large. |
Understand your point but probably an optimization that can come later, remember when you call imagine we do load at least 7GB from the internet/into memory. I don't think anyone will ever queue up enough prompts to even get within an order of magnitude of the current memory/network usage. |
Really rough code here. I don't like naming and maybe interface. but i think the idea works class ImagineImage:
def __init__(self, filepath=None, url=None, pil_img=None):
self.filepath = filepath
# etc
# add validation checks
def as_pil_img(self):
if self.pil_img is not None:
return self.pil_img
if self.url:
self.pil_img = load_img_from_url(self.url)
elif self.filepath:
self.pil_img = load_Img_from_path(self.filepath)
return self.pil_img |
Especially because we're already using lots of memory we should be careful about using more. |
I'm on the fence about where the image strength argument should exist. Especially since I'm playing with alternative img2img methods which may take different arguments |
This isn't the best implementation but it's a start.
Some problems with this approach is:
Another option but more work for the caller is to allow a user to supply a PIL image in the ImaginePrompt